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ABSTRACT 


This  thesis  reoorts  the  development  of  a  seamented 
memory  manager  for  the  UNIX  ooeratinq  system  on  a  PDP-11/50 
minicomputer.  Considerea  in  detail  is  the  application  of 
this  memory  manager  to  data  segment  boundary  alignment  and 
system  Drotection  in  a  multiported  memory  conf iquration. 
Recommendations  are  provided  for  the  intearation  of  this 
operating  svstem  into  the  total  Naval  Postgraduate  School 
Signal  Processing  ana  Display  Laboratory  environment. 
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I.   INTRODUCTION 


The  goal  of  the  i-iaval  Postgraduate  School  Signal 
Processing  and  Display  Laboratory  is  t o  provide  a  facility 
for  research  and  eaucat ion  in  the  field  of  computer  science. 
The  laboratory  is  built  around  a  oair  of  Diaital  Fguioment 
Corooration  PDP-11/50  orocessors.  One  processor  is 
primarily  used  to  service  multiuser  Drogram  develocment 
activities.  The  other  orecessor  suoports  several  graDhics 
aisDlay  devices  ana  orovides  a  dedicated  environment  for 
research  and  develooment  in  the  areas  of  operatina  s  v  s  t  e  n*  s  > 
computer  graphics  ana  signal  orocessing.  Figure  1  shows  the 
present  hardware    configuration  of  the  laboratorv. 

The  UNIX  operatinc  system  17]  /  a  time-sharina  svstem 
developed  at  Pell  Laboratories,  was  chosen  as  the  system 
best  suited  to  supoort  the  goals  stated  above.  UNIX's 
inherent  file  svstem  flexibility  and  the  availability  of 
system  source  coae  written  in  the  high  level  Drogrammina 
language/  "C",  orcvide  an  excellent  environment  for 
operating  system  develooment  and  research.  The  availaoilitv 
of  a  dedicated  processor  as  a  aeve 1 op^en t a  1  tool  further 
enhances  this  environment. 

Due  to  the  unigue  and  demanding  regui regents  placed  on 
the  display  processor's  ocerating  system  by  grachics  devices 
and  signal  processing  eauioment/  it  was  aeter^ined  t- n  a  t  the 
standard  version  of  UNIX  in  use  (  henceforth  simply  referred 


to  as  UNIX  )  was  unsatisfactory.  This  thesis  proooses  an 
extension  to  the  UNIX  system  in  the  form  of  a  new  memory 
management  scheme.  Ihe  approach  taken  was  to  imDlement 
process  segmentation  with  provision  for  data  space 
allocation  and  alignment  within  a  specified  memory  region. 
This  approach  was  feasible  and  attractive  because  the 
PDP-11/50  is  eguiopea  with  a  memory  manaaement  unit  ( M M U ) 
that  supports  seamentaHon.  Additional  1  y  »■  segmentation 
provides  extra  flexibility  in  resident  process  man i ou 1  a t i on  . 
UNIX  allocates  process  soace  as  a  single  contiguous  unit  in 
main  rremory.  Seamentation  allows  management  of  orccess 
segments  as  separate  entities.  This  provides  the  necessary 
tool  for  selective  allocation  of  memory  soace  to  an 
individual  seament . 

This  latter  feature  is  particularly  attractive  in  a 
svstem  confiaured  with  multioorted  memory.  As  shown  in 
Figure  1/  the  aisolay  processor  has  access  to  two  dual- 
ported  memory  areas?  one  shared  with  a  signal  processina 
controller/  the  other  shared  wifh  a  slave  processor  for  the 
refresh  araphics  display  devices.  Due  to  the  real-time 
requi  regents  of  these  devices/  independent  access  to  data  in 
the  shared  region  is  necessary.  Otherwise/  tne  displav 
processor  will  not  be  able  to  support  multiprogramming.  A 
segmented  memorv  rranaaer  would  provide  the  features 
necessary  to  support-  these  real-time  reou i r emen t s . 

Two  modifications  of  the  UNIx  operatina  svstem  were 
implemented  and  tested  as  a  result  of  this  thesis.  One  was 
a  previously   designee   [  ^  ]  ,   put   un implemented/   segmented 
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memory  manager  version  (SUNIX).  The  other,  a  shared- 
segmented  version  (S$UNIX)»  was  a  further  modification  of 
SUNIX  which  implemented  the  aHqnment  of  a  orocess's  data 
soace  within  a  shared  memorv  reqion.  Real-time  processing 
was  supoorted  bv  lockino  the  orocess  image  in  main  memory 
once  the  shared  region  had  been  acquired. 

Testing  of  SUNIX  and  SSUNIX  included  benchmark 
measurements  and  operation  in  the  general  multiuser 
environment.  Performance  was  almost  identical  to  that  of 
UNIX.  Additionally/  SSUNIX  was  tested  on  the  display 
processor  and  successfully  fulfilled  the  objective  of  data 
soace  alignment  with  system  orotection.  Amplification  of 
these  results  is  orovided  in  Chapter  V  of  this  thesis.  In 
addition,  recommendations  are  included  for  aoplications  and 
utilization  of  SUNIX  and  SSUNIX  in  the  Sional  Processing  and 
Oisolay  Laboratory. 
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II.   BACKGROUND 


A.   PREVIOUS  WORK 

Three  Drevious  thesis  orojects  which  are  closely 
associated  with  the  development  o*  SUNIX  ana  SSUNIX  are 
discussed  below.  It  should  be  noted  that  a  SDeci  f ic  area  of 
concern  in  all  three  oaoers  is  the  development  of  system 
supoort  for  the  soec i a  1  devices  on  the  display  crocessor. 

1.   Partitioned  Segmented  Memory  ^anaaer 

In  this  thesis  [4],  E^ery  reports  an  investigation 
of  the  apo 1 i cap i 1 i t y  of  oaaing  ana  segmentation  to  memory 
management  in  UNIX.  Two  memory  managers  were  designed  to 
support  this  investigation:  a  oartitioned  seamented  version 
(PSUNIX),  and  a  simpler  segmented  version  CSUNIX).  The 
primary  consideration  in  the  design  effort  was  that  the 
segments  be  separate  and  independently  manageable  in  main 
memory.  The  segmentation  chosen  was  the  existino  natural 
division  into  a  process  control  o  1  o  c  *,  /  a  data  seamen*- 
(includina  non-sharec  text)/  and  a  User  stack.  Shared  text 
segments  were  handlea  in  m  u  c  n  the  same  manner  as  in  UNIX. 
SUNlx  was  designee  to  manaae  e  act\  complete  seomenf 
inaependently.  It  was  this  aesign  effort  that  nroviaea  a 
foundation  for  the  development  of  S  S  U  i\  I  X  .  P  S  U  N I X  further 
broke  down  each  of  tne  seoments  into  variaole-size  blocks. 

Testing   of   P  S  U  N  T  X   was    accomplished    bv    usina 
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benchmaric  measurements  to  analyze  its  performance  in 
relation  to  UNIX.  The  experimental  results  clearlv 
indicated  that  the  performance  of  PS UNIX  and  UNIX  were 
nearly  identical  over  a  wide  range  of  available  User  memory 
space.  Emery  suggested  that  this  aporoximate  eaualitv  of 
pergormance  indicated  that  the  disadvantaae  of  the  increased 
amount  of  swaooing  in  P  S  U  N  I  X  was  offset  by  a  reduction  in 
the  number  of  orocesses  swaDpea.  He  attributed  this  to 
reduced  external  fragmentation  with  PSUM IX.  However,  aue  to 
the  relative  complexity  of  PS UNIX,  Emery  recommends  that  the 
simoler  SUNTX  be  comoleted  and  implementeo  as  a  viable 
alternative. 

2.        Int er-Processc r  GraDhics  Support  System 

Visco  [121  investigated  a  multiple  orocessor  system 
conf  iaurat  ion  to  sucpct  a  real-time,  interactive  graohics 
package.  UNIX  was  reoesiqned  to  implement  a  real -time 
system  call  and  a  master-slave  relationshio  between  the 
disolay  orocessor  and  a  dedicated  graphics  processor. 
Soecificallv,  he  designed  the  system  support  routines 
necessary  for  integration  of  the  PDP-11/50/  PDP-11/34,  and 
Vector  General  (  v  G  )  Display  Processors.  For  ^esn'na 
purooses,  inter-processor  communications  were  simulated  on 
the  PDP-11/50,  since  the  DDP-ll/34  slave  orocessor  was  not 
available  for  use. 

The  master-slave  orocessor  configuration  was 
conceivea  as  an  answer  to  the  oroblem  of  refresh  graohics 
devices  having  a  hian  level  of  direct   memory   access   TDMA) 
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requests  and  a  reoui  rement  for  real-time  system  supcort . 
D  M  A  is  the  transfer  of  data  directly  to  or  from  memory  by  a 
peripheral  device/  without  processor  suoervision.  This 
con f i qurat i on  reauired  shared  memory  and  the  system  support 
software  to  a  1  i  q  n  a  process  image  in  the  shared  reqion. 
Memory  management  hardware  on  the  slave  processor  f  2  ] 
permitted  a  32  tnousand  (K)  word  address  range.  The  svstem 
designed  ov  visco  allocated  the  entire  process  imaae  on  a 
3  2  K  word  boundary.  System  Drotect ion  was  not  achieved  since 
other  processes  were  allowed  to  overlap  into  this  region. 

Visco  sugaested  an  implementation  of  Emery's  SUMIX 
as  a  method  of  allocating  on  1 v  the  qraphics  process's  data 
space  to  the  shared  region  of  memory.  Since  O^A  by  the 
slave  processor^  acting  in  behalf  of  the  graphics  device/ 
was  highly  concentrated  in  data  soace/  this  memory 
allocation  scheme  would  more  efficiently  utilize  the  limited 
amount  of  shared  memory.  S  S  U  N I X ,  with  the  added  features  of 
generalized  multioorted  memory  applications  and  system 
protection/  was  developed  as  a  result  of  this  sugaestior. 

3.   Loosely -Counted  Multiprocessor  System 

visco's  work  was  directed  primarily  toward  the  main 
processor  in  the  prooosed  mu 1 t i orocesso r  system  for  tne 
laboratory.  A  thesis  by  ^  r  a  y  I q  1  addresses  the  development 
of  ar\  operating  system  for  the  slave  processor.  Although 
not  directly  related  to  the  oroblem  of  memory  management  in 
UNIX,  this  paper  is  mentioned  here  to  emphasize  the  oeneral 
trena  of  thesis  work  cone  in   supoort   of   the   laooratorv's 
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refresh  graohics  devices.  Furthermore*  recommendations  in  a 
later  chanter  of  this  oaoer  soecificallv  adaress  the 
integration  of  SSUNIX  into  the  multiprocessor  environment. 

B.   GENERAL  SYSTEM  PROPOSAL 

As  indicated  in  the  orevious  section/  the  soeci^ic 
system  proDosed  by  this  thesis  was  desianed  primarily  to 
perform  data  space  alignment  in  a  shared  memory  area  *or 
resident  signal  process  ina  and  refresh  argphics  processes. 
However,  the  actual  modifications  to  UNIX  were  designed  to 
offer  more  general  applications.  SUNTx  was  implemented  as  a 
general  ourpose  operating  system  with  segmented  memory 
management.  The  differences  between  UNIX  and  SUMIX  are 
transparent  to  the  User.  SSUNIX  provides  the  ability  to 
align  a  process's  aata  space  within  any  given  area  of  User 
memory  space.  Location  and  size  of  this  memory  reaion, 
which  was  intended  to  corresoona  to  shared  memory  assets, 
can  be  specified  at  svstem  aeneration  time.  The  limitations 
of  UNIX  in  a  system  confiaured  with  devices  which  aemand 
heavy  D  M  A  and  real-time  svstem  suDDort  are  discussed.  Tne 
general  concepts  behind  the  aesign  of  SUNIx  and  SSUNIX  are 
a  1  so  present  ed . 

1.   Limitations  of  the  Dresent  System 

a.   bus  Allocation 

As  shown  in  Figure  1  ,     all   PQP-11/50   components 
and   oerionerals   connect  to  and  communicate  with  each  other 
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over  a  high-speed*  b i d i rec t i ona 1 /  asynchronous  bus  known  as 
the  UNIBUS  (3].  Devices  gain  access  to  the  UNIBUS  vid  an 
arbitration  unit.  This  unit  arants  bus  mastership  based  on 
a  multilevel  priority  scheme.  Each  device  on  the  UN  lb US  is 
assigned  a  hard-wirea  priority  which  is  recoanizea  by  the 
arbiter.  A  device  is  aranted  immediate  mastersnip  when  a 
request  is  made  and  no  device  of  equal  or  higher  priority 
has  control.  DMA  reouests  from  oerioheral  devices  hav* 
highest  priority.  The  central  orocessing  unit  (CPU)  has  the 
capability  to  control  or  release  the  bus  by  varying  its  own 
priority  level.  This  makes  it  possible  for  devices  to 
access  main  memory  with  almost  no  processor  intervention. 

Devices  which  reguire  a  large  amount  of  DMA 
place  heavy  demands  on  the  UNIBUS.  A  problem  arises  in  a 
multiorogrammina  environment  when  a  process  is  running  at  a 
high  schedulina  oriority  (as  with  real-time  processes),  and 
also  reauires  nigh  criority  and  heavy  bus  utilization  •'or 
DMA.  In  this  case*  all  other  Drocesses  are  essentially 
susoended  since  thev  cannot  gain  access  to  the  UNIBUS. 
Refresh  graphics  devices  reauire  heavy  bus  utilization  for 
processing  the  display  list.  In  the  case  of  the  VG  devices 
in  the  laboratory*  the  display  list/  located  in  the  resiaent 
graohics  orocess's  data  soace*  must  be  processed  every  one- 
fortieth  of  a  second.  It  is  thus  necessary  to  lock  the 
active  display  list  in  memory.  I  f  the  list  were  not"  in 
memory  at  the  time  of  a  refresh  cycle  an  inorainate  delay 
would  occur,  causina  tne  display  to  flicker  or  fade. 

As   noteo   previously*   dual-oorteo   ^e^ory   was 


1  7 


conceived  as  a  solution  to  these  problems.  With  the 
peripheral  processors  each  assigned  a  seDarate  bus  attached 
to  memory  ports  ODposite  the  main  processor,  interference 
durino.  DMA  could  be  virtually  eliminated.  The  oroolem  which 
remained  was  the  allocation  of  a  process's  data  soace  to  one 
of  the  shared  memory  areas.  Visco's  desian  attemoted  to 
solve  this  Droblem  specifically  for  VG  processes.  S  S  U  N  I  X 
was  designed  to  solve  the  problem  for  more  general 
aop 1 icat ions. 

b.   Memory  Allocation  Scheme 

In  UNIX,  while  the  processor  is  executino  in 
oenalf  of  a  process,  its  image  must  reside  in  main  memory  as 
a  sinale  contiguous  unit.  Unless  swappina  is  necessary,  the 
image  remains  in  memorv  durino  the  execution  of  other 
processes.  When  the  CPU  is  executinq  a  process,  M  M  U 
registers  ^re  loaded  so  the  process  can  access  onlv  its  own 
image  and,  if  applicable,  a  text  segment  shared  with  other 
processes . 

The  memory  allocation  scheme  used  in  UNIX  is 
Dased  on  a  "first-fit"  alaorithm.  That  is,  the  process 
imaae  is  allocated  space  in  the  first  free  area  in  the 
system's  free-list  which  can  accomodate  it.  With  this 
scheme,  selective  allocation  and  alignment  of  memory  space 
in  a  Darticular  reqion  of  memorv  is  impossible.  Tni  s  is 
unsatisfactory  in  a  system  configured  with  multioorted 
memory.  As  an  example,  the  Computer  Sianal  Processors 
Incoroorated  CSP  125  controller  can  access  only  tkaf  cortion 
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of  memory  indicated  in  Figure  1.  Any  process  that 
communicates  with  the  CSP  125  must  have  its  data  space 
located  in  that  area  of  memory. 

2. .   General  Features  of  the  Prooosed  System 

a .   Segment  a t i on 

The  initial  decision  that  had  to  be  made  to 
solve  the  problems  stated  above  was:  what  tvpe  of  memorv 
management  modifications  to  UNIX  were  reguired  to  provide  a 
general  and  efficient  ooerating  svstem  wnich  would  support 
alignment  of  a  resident  process's  data  space  in  a  aiven 
region  of  memory.  The  segmented  memory  manaaer  desianeo  by 
E.mery  (SUNIX)  was  chosen  as  a  basis  for  the  intended 
modifications.  Segmentation  had  several  advantages  which 
maoe  this  choice  attractive.  Process  imaaes  in  UNIX  consist 
of  several  logically  independent  segments.  Although  not 
managed  seoarately*  this  natural  division  orovia^s  an 
aopealing  basis  for  seamen t a t i on .  Mod i f i c a t i ons  to  tne 
existing  memory  management  routines  to  imolement  SUN IX  were 
straightforward  and  relatively  si^ole. 

The  segmentation  cnosen  also  proved  to  be  an 
efficient  way  to  hanole  dynamic  changes  in  the  size  of  User 
data  and  stack  areas.  In  UNIX,  when  the  User  scace  crows 
beyond  tne  available  continuous  memorv  soace;  it  is 
necessary  to  reestablish  rhe  entire  orocess  image  in  main 
memorv.  This  is  accomplished  by  cooyinc  the  process  image 
to  a  new  free  area  of  sufficient  size.  Since  t-here  is  no 
hardware   facility   on   the   p  D  P  -  11  /  5  0  for  a  "o'oc<  move"  in 
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memory,  this  is  a  major  source  of  memory  management 
overhead.  The  cost  of  the  copv  ooeration  is  about  1  <"> 
micro-seconds  oer  wore  f<4]  .  This  figure  is  even  worse  if 
sDace  is  not  readily  available  for  the  larqer  image  and 
other  processes  have  to  swaoped  out  to  make  room.  To  SUM  IX 
the  User's  data  and  stack  are  managea  i naependen t 1 y .  Growth 
of  either  area  reauires  rees t ab  1  i s h i no  only  that  seament  in 
memory.  Total  overhead  due  to  dynamic  in-core  exoansion  is, 
therefore,  reduced. 

b.   Data  Space  Alignment 

After  decidina  on  SUN IX  as  tne  operatina  system 
which  would  oest  serve  the  purposes  of  this  thesis,  a  method 
of  Dositionina  a  orccess's  data  soace  at  a  particular 
location  in  main  memory  had  to  be  'aeve 1  oped .  detailed 
analysis  of  the  memorv  management  routines  in  both  SUNIX  and 
UNIX  was  necessary  before  oroceeding.  The  method  chosen, 
and  implemented  in  SSUNIX,  was  a  direct  extension  of  SUNIX. 
No  modification  to  the  segmentation  scheme  was  necessary, 
and  onlv  minor  modifications  to  the  other  memcrv  management 
routines  were  required.  The  aeneral  aporoacn  taken  was  to 
implement  the  necessary  changes  by  adding  several  system 
routines  to  acquire,  allocate,  and  release  a  shared  memorv 
asset.  System  calls  were  imDlemen^ed  to  perform  these 
functions  for  processes  requiring  shared  memory. 

Providing  system  DroteCion  was  a  secondary  goal 
in  the  desian  of  a  t  e  m  o  r  y  manager  for  SSUNIX.  Tne  concept 
of     system  protection  implies  that  l nadve r t en t  destruction  of 
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vital  process  information,  particularly  the  process  control 
information  used  by  the  operating  sytem,  will  not  occur. 
Address  range  limitations  of  the  peripheral  processors 
prevent  their  manipulation  of  data  in  memory  locations 
outside  of  the  s  h  a  r  e  a  region.  SSUNIX  allows  only  the  data 
space  of  processes  communicating  with  these  devices  in  this 
region.  The  combination  of  these  two  features  Droviaed  the 
svstem  orotection  desired. 
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III.   THE  UNIX  OPERATING  SYSTEM 


Thus  f ar  in  this  thesis*  the  UNIX  operating  system  has 
been  discussed  in  general  terms.  This  chaoter  orovides  a 
more  detailed  discussion  of  the  conceots  of  svstem 
operation.  Conceots  in  the  design  of  the  memory  managers  in 
UNIX,  SUNIX  and  SSUNIX  are  also  presented.  This  cnapter 
provides  the  backaround  necessary  for  understanding  the 
moai f i ca t i ons  made  to  UNIX  to  implement  SUNIX  and  SSUNIX. 

A.   CONCEPTS  OF  OPERATION 

UNIX  (71  is  a  terminal  oriented*  time-sharing  operating 
svstem  developed  at  Bell  Laboratories  for  the  Digital 
Eauipment  Corporation  (DEC)  PDP-11  family  of  minicomputers. 
Most  of  the  source  code  for  UNIX  is  written  in  "C"  (Ql ,  a 
high  level  systems  implementation  lanauage.  The  remainder 
of  the  source  is  written  in  "as"  (10],  a  Bell  Laboratories 
variant  of  PDP-11  assembly  languaae. 

Multi-tasking  in  UNIX  is  performed  on  a  basic  unit  o  * 
work  called  the  orocess.  A  process  consists  of  system 
control  information,  executable  instructions*  ana  data, 
/jhen  the  operatina  system  is  "bootstrapped"  into  memory  at 
svstem  initiation  t  i  m  p  ,  it  "handcrafts"  its  first  two 
processes.  Process  0  is  f  he  master  control  cocess  (the 
scneauler  "loop")   which   executes   until   UNIX   terminates. 
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Process  1  initializes  the  ooerating  environment  for  other 
processes  in  such  a  manner  that  all  subseouent  orocesses  are 
its  descendents.  All  other  processes  are  executions  of 
proaram  files  from  the  UNIX  file  system. 

Descenaents  of  a  process  are  created  by  execution  of  the 
"fork"  system  call.  This  svstem  call  replicates  the  callina 
process*  creating  a  new  (child)  process  that  has  a  unioue 
process  number.  The  oriqinal  orocess/  called  the  parent? 
can  continue  execution  or  temporarily  susoena  itself  until 
the  child  terminates.  A  child  orocess  mav  either  continue 
execution  of  the  same  program  or  invoke  a  new  Drogram  into 
execution.  New  processes  are  invoked  by  "exec%  a  system 
call  that  "overlays"  the  callina  orocess  with  an  executable 
file  from  the  file  system.  Child  processes  may  also  spawn 
children  of  their  own.  rthen  any  child  completes  execution* 
it  terminates  by  means  of  the  "exit"  system  call.  "Exit" 
notifies  the  oarent  of  the  child's  termination. 

The  primary  role  cf  Process  1  is  to  create  a  child 
process  for  each  of  the  terminals  in  the  system.  These 
processes  ooen  their  assigned  terminals*  oromot  for  a  user 
to  log  in*  and  then  await  a  reoly.  Once  a  user  nas  logged 
in*  the  child  invokes  a  new  croaram  (using  "exec")  called 
the  Shell.  The  function  of  the  Shell  is  to  interpret 
commanas  f*-om  the  terminal  and  create  children  which 
accomplish  the  desired  ooerat  io".  :.«f  h  e  n  the  user  logs  off* 
the  Shell  orocess  for  his  terminal  is  terminatec.  process 
1*  *hich  is  then  notified  of  that  child's  demise*  creates 
anotner  chila  for  the  terminal.   The  new  child   r  p  o  d  e  n  s   the 
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terminal  and  oromots  for  another  1 oq  in. 

From  the  User's  point  of  vi*»w*  the  most  imoortant  role 
of  UNIX  is  to  provide  a  file  svstem  [7],  There  are 
basically  three  kinds  of  files  suoported  bv  the  system: 
ordinary  disk  files*  directories*  and  special  files. 
Ordinary  files  contain  whatever  information  the  User  places 
on  it.  Source  orcgrams*  object  modules  generated  oy 
comoilers  or  assemblers*  and  oure  text  are  examples  of 
ordinary  files.  Directories  orcvide  a  maopinq  of  oroinarv 
file  names  to  the  files  themselves;  thereby  inducing  a 
structure  on  the  file  system.  All  files  in  the  svstem  mav 
be  located  by  tracing  a  path  from  the  "root"  directorv  to 
the  desired  file.  User  interface  to  each  inDut/ouput  (I/O) 
device  supported  by  the  system  is  throuah  a  de v i ce-soec i f i c 
SDecial  file.  with  this  scheme/  I/O  devices  can  pe  treated 
as  ordinary  files. 

B.   MEMORY  MANAGER  DESIGN 

The  UNIX  memory  manager  is*  in  conceot »  a  relocatable 
partitioned  memorv  manaoe  r  with  swacpina  ana  limited 
segmentation.  While  the  orocessor  is  executing  in  behalf  of 
a  orocess*  the  process  image  must  reside  in  a  continuous 
region  in  main  memory.  As  already  explained*  ^  u  r  i  n  g  the 
execution  of  ot^er  crccesses*  a  process  may  remain  in  memory 
unless  scheduling  of  a  hioher  priority  orocess  forces  it  to 
be  swaoped  out  (cooied)  to  the  swao  device.  U r '  IX  orocesses 
are  logically  divided  into  three   carts:   the   1 '  v  E  C  T  0  P  *   the 
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User  data  soace,  and  the  User  processor  stack.  If  a  process 
requires  use  of  shared  text,  its  data  space  contains  onlv 
data.   Shared  text  is  managed  separately. 

The  UVECTOR  contains  all  process  status  information 
required  bv  UNIX  while  the  process  is  resident  in  core. 
Uther  Drocess  status  information,  which  must  remain 
addressable  throuahout  the  life  of  the  orocess/  is  contained 
in  a  system  control  Dlocic  called  a  PROC.  In  the  case  of 
shared  text,  the  PRUC  contains  a  pointer  to  vet  another 
system  control  block  called  a  TEXT.  This  block  contains  all 
information  necessary  to  control  the  sharing  of  a  text 
segment  Dy  one  or  more  processes.  Sharea  text,  if  reauired, 
is  established  in  memory  indeoenaentlv  of  the  orocesses 
which  are  sharing  it.  If  a  process  shares  text,  "exec" 
checKS  to  see  if  a  copy  of  the  text  segment  is  already 
availaole  in  the  system.   If     it  is  not,  a  copy  is  created. 

User  address  space  of  a  text-sharing  process  fav  oe 
created  with  seoarate  instruction  soace  (I-scace)  ano  oata 
SDace  (D-spaceJ,  or  with  combined  I-soace  and  D-SDace.  user 
address  space  for  non-sharino  orocesses  is  estaolished  with 
combined  instruction  and  data  soaces.  If  the  I-soace  and 
D-soace  of  a  orccess  ^re  combined,  there  is  no 
differentiation  between  instructions  and  data.  The  file 
type  ( 7  ]  of  an  executable  file  is  used  by  "exec"  to 
establish  a  seoaration  flag  in  the  UVECTOR.  This  f 1 aa  is 
used  to  control  the  method  by  which  the  address  soace  for  a 
text  sharing  crocess  is  established.  The  scared  text 
segment   of   a   process   with'  seoarate   address   soaces   is 
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addressed  beginning  at  User  I-space  address  o;  data  is 
addressed  beginning  at  User  O-soace  address  0  .  If  a  process 
with  compined  address  spaces  has  shared  text/  the  text 
segment  is  addressable  beginning  at  address  0  in  both  I - 
soace  and  D-snace.  Its  data  is  addressed  in  b  o  f  h  I-space 
and  0-spacef  beainning  at  the  first  4K  word  boundary  aoove 
the  shared  text  segment.  For  processes  without  shared  text* 
the  text  is  addressed  beginning  at  address  0  in  the  combined 
I-soace  and  O-soace?  and  its  data  is  addressed  beainninq  at 
the  first  word  boundary  above  the  text.  The  User's 
processor  stack  is  addressed  extending  downwara  from  the 
highest  address  in  D-space  or  combined  I-space  and  D-space. 

PDP-11/50  oaae  address  registers  (PARsJ  ana  page 
descriptor  registers  t  P  D  P  s  1  are  loaded  when  a  process  image 
is  brought  into  memorv  or  its  address  soace  is 
rees tap  1  i shed .  PARs  are  used  by  the  WMU  to  translate 
virtual  addresses  to  chvsical  memory  addresses.  PDRs  are 
used  to  describe  a  se*"  of  attributes  about  a  resident 
process's  pages.  A  page  in  UNI*  can  oe  thought  of  as  a 
partition  of  a  process  imace  which  can  be  up  to  4K  words  in 
length.  Access  control  specified  in  the  p  C  R  s  is  read  only 
for  shared  text  pages  and  read-write  for  all  other  naaes. 

User  data  soace  may  vary  dynamically  if  required  ourina 
execution  of  a  process.  A  system  call/  "break"/  is  provided 
in  UNIX  to  alter  the  size  of  the  data  area .  Additionally / 
the  size  of  a  process  image  may  be  increase o  cv  dynamic 
growth  of  the  User  processor  stack.  When  this  occurs*  the 
svstem   automatically  increases  the  amount  of  scace  provided 
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for  the  process.  In  both  of  these  cases/  UNIX  must 
reestablish  the  entire  process  image  in  mair  memory.  As 
mentioned  oreviously,  one  of  the  primary  benefits  of 
segmentation  is  indicated  here.  SUNIX  and  SSUr!IX  reauire 
that  only  the  segment  whicn  changes  size  be  rees t ao 1 i shed . 

1 .   Segment  a t  i  on 

Segmentation  of  shared  text  is  already  well 
supported  in  UNIX.  SUNIX  and  SSUNlX  further  divide  process 
imaqes  into  the  three  natural  segments  mentioned  before: 
UVtCIOR,  data  space  (including  non-shared  text  1 /  ana  User 
stack.  Allocation  of  memory  space  for  a  process  is 
accomplished  by  separately  establishina  each  segment  in  a 
free  area  large  enough  for  it.  Contiguous  allocation  in 
memory  is  possible,  but  not  required.  Swac  space  for  a 
process  is  still  allocated  in  a  cont iauous  oartition  en  the 
system's  swao  device.  However,  due  to  the  separation  of 
segments  in  main  memory/  uo  to  three  cooy  operations  are 
required  each  time  a  process  is  swapped  to  or  from  the  swao 
device.  In  u  N  I X  ,  only  one  copy  operation  is  reauireo. 
Thus,  there  is  an  increase  in  svstem  overhead  with  seomented 
memory  management.  There  is,  nowever,  a  compensating 
advantaae  to  segmentation:  a  reduction  of  overhead  (.seament 
copying)  results  *rom  independent  manaaement  of  ridfd  and 
stacK  segments  if  dynamic  growth  of  one  of  these  sea^ents  is 
requ i red  . 
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2. .   Allocation  of  Memorv  Soace 

The  basic  quantum  of  memorv  soace  in  ''NIX  is  a 
64-byte  area  called  a  Dlock.  This  is  the  smallest  quantum 
supDortea  by  the  PDP-11/50  MMU.  Memory  soace  for  each 
process  is  assigned  from  a  free  memory  mac  maintained  dv  the 
operating  system.  This  map*  which  is  established  at  system 
initiation  time  based  on  ohysical  memory  configuration* 
contains  the  base  address  and  size  (in  blocks)  of  each 
unallocated  area  of  User  -nemory  scace.  Addresses  in  the  mao 
are  increasina  in  order  and  represent  the  ohvsical  block 
number  of  the  free  area  to  which  thev  refer.  The  operatinq 
system  is  established  beginning  at  ohvsical  address  0.  User 
memory  space  beains  at  the  first  block  boundarv  above  the 
system  code . 

Maintenance  of  the  free  memorv  mac  is  performed  ov 
the  memory  management  orimitives  "malloc"  and  "mfree". 
These  system  routines  are  also  generalized  to  cerfnrm 
maintenance  of  all  other  svstem  free  maps?  for  examcle*  tne 
swao  man*  and  the  shared  memory  maps  (described  later)  in 
SSUMIX.  The  function  of  "malloc"  is  to  locate  an  area  of 
given  size  in  the  given  maor  update  the  map  to  reflect  the 
allocation  of  the  area;  and  then  return  the  physical  block 
number  of  the  allocated  area  to  the  calling  routine.  The 
algorithm  used  in  "malloc"  is  "first-fit".  That  is*  tne 
free  mao  is  searched  sequentially*  beainnina  with  the  first 
entry*  until  an  area  of  sufficient  size  to  saMsfv  tne 
request  is  found.  If  the  requested  space  is  no*"  available* 
a   zero   value   is   returned  fo  the  caller.   The  ^unction  of 
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"mfree"  is  to  free  the  area  specified  by  t^e  callina 
routine.  The  reaion  soec  i  f  i  ed  is  sorted  Dack  int-o  the  free 
map  and  combined  on  one  or  both  ends  if  possible.  In  UNIX, 
processes  are  allocated  space  based  on  the  «ize  of  the 
entire  process  image.  In  SUNIX  and  SSUNIX,  each  seament  of 
a  orocess  is  allocated  memory  space  seoarately  based  on  the 
segmen  t  size. 

3.   Multiported  Memory 

Regions  of  multiported  memory  are  often  desirable  to 
support  peripheral  devices  which  have  uiioue  DMA 
requirements.  Examoles  are  devices  which  have  hardware 
address  ranoe  limitations  or  require  real-time  memory 
access.  Specific  aopli  cations  of  multioorted  memory  in  the 
Signal  Processinq  and  Oisolay  Laboratory  have  already  been 
di  scussed. 

To  support  multiported  memory,  the  operat inq  svstem 
must  be  able  to  align  a  orocess  or  orocess  sec-ent  in  the 
multiported  memory  reaion.  UNIX  does  not  have  this 
capability.  As  explained  in  the  previous  section,  "  m  a  1  1  o  c  " 
assigns  memory  space  from  the  User  free  mac  r-ised  on  a 
"first-fit"  algorithm.  With  this  alaori  thn",  alignment 
within  a  soecified  region  of  memorv  would  ~e  purely 
coincidental.  Furthermore,  since  U  M  A  oy  a  peripheral  device 
to  UvECTOR  or  stack  addresses  violates  system  security,  only 
the  data  segment  is  claced  in  the  multiported  reaion.  I'his 
implies  that  segmentation  is  a  desirable  memory  m  anagemenf 
scheme   in  a  system  confiaured  with  multioorted  memory.   For 
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this  reason,  SUNIX  was  chosen  as  the  basis  for  development 
of  mu  1  t  i  por  t  ed  memory  system  support.  Mthouah  there  was  no 
provision  for  data  seament  alignment  in  3  U  N  I  X  ,  the  method  o  * 
process  seamentation  directly  suoported  the  desion  effort 
undertaken  by  this  author. 

In  order  to  invest iaate  multiDorted  memorv 
applications  in  UNIX,  a  shared-segmented  memorv  "anaoer 
(SSUNlx)  was  desianea  and  implemented.  SSUNIX  cr^vio°o  the 
capability  to  alion  a  calling  process's  data  segment  in  a 
shared  memory  region,  and  to  ensure  system  projection  by 
clearing  all  other  processes  from  that  region.  c  r  e  e  memorv 
maps  were  established  and  maintained  for  each  scared  core 
area.  Processes   recuested   the   shared  memorv  asset"  via  a 

svstem  call  ("getshr").  A  system  routine  *  a  s  designed  which 
checked  the  User  free  memory  map  to  determine  if  the 
reguested  region  was  free.  If  the  area  was  free,  it  was 
removed  from  the  User  free  memorv  mao  and  the  Cat-a  space  of 
the  calling  User  process  was  moved  to  the  snared  region. 
The  "malloc"  svstem  call  was  used  to  allocate  scace  for  the 
data  segment  in  the  reguested  shared  reaion.  If  the  area 
was  in  use  ov  another  memory-sharing  process,  the  data 
segment  of  the  callinc  process  was  simply  allocated  in  *he 
shared  memory  map  and  then  moved  to  the  region.  Tf  the  area 
«as  in  use  bv  other  non-memo ry-s ha r i ng  processes,  these 
processes  were  s  *  a  o  c  e  d  out  of  memory  until  t  ~  e  area  was 
clear.  The  data  seament  of  the  callino  User  process  was 
then  allocateo  in  the  shared  memory  map  ano  moved  to  the 
r«*g  i  on  . 
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In  each  o*  the  above  cases*  after  a  shared  memory 
region  had  been  acauired  for  a  memo rv-shar i na  Drocess*  non- 
memory-sharina  Drocesses  were  not  allocated  SDace  within  the 
bounds  of  the  snared  region.  Add i t i ona I  1 y f  the  cal  I  ina 
process  was  locked  into  memory  so  it  would  not  be  swapped 
out  of  the  area.  Another  system  call  ("freeshr")  was 
implemented  to  release  a  orocess's  shared  memory  asset  and 
unlock  the  orocess  i^aoe.  This  system  call  updated  the 
shared  memory  map.  If  no  other  memo r y-sh a r i ng  orocesses 
remained  in  the  reaion,  the  entire  shared  memory  area  was 
returned  to  the  User  free    map. 
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TV.   MODIFICATIONS  TO  UNIX 


A.   GENERAL 

Modifications  to  tne  UNIX  operating  system  to  Droauce 
S  U  N  I  X  were  performed  h  y  Emery  [U]  in  mid-1976.  The  approach 
taken  in  the  desian  was  to  wake  the  general  structure  of 
memory  management  familiar  to  those  who  understood  the 
structure  of  UNIX.  This  aporoacr,  led  to  a  weM -designed 
ooerating  system  which  readily  suDported  further 
modifications  and  debugging.  However,  due  to  greater 
emphasis  on  the  completion  and  testing  of  a  Partitioned 
segmented  memory  manacer  CPSUMIX),  SUN  IX  was  not  i-nplemented 
at  that  time.  Final  implementation  ana  testing  of  SUN IX  was 
a  primary  goal  of  this  thesis  project.  SSU*'IX  ^a5  to  be  a 
direct  extension  of  SUN  IX.  For  this  reason,  modifications 
to  UNIX  reguired  to  implement  SSUN IX  e°comoass  those  made 
for  SUNIX. 

The  changes  necessary  to  implement  process  segmentation 
with  data  segment  alignment  affected  five  general  areas: 

1  .   Cont  ro 1  Blocks 

2. .   Memory  ^anaoement 

3.   Swap  Soace  Allocation 

<4 .   Shared  Memory  Allocation 

5.   Support  Proorams 
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Each  of  these  areas  is  discussed  in  a  subseauent  section  of 
this  chapter.  The  ^Dcendices  to  this  thesis  orovide  further 
documentation.  Information  on  control  block  modifications 
is  found  in  Aopendix  A  .  ^  e  m  o  r  y  management  and  shared  core 
allocation  modifications  are  described  in  Aopendix  8. 

6.   CONTROL  BLOCKS 

UNIX  control  blocks  are  data  structures  used  by  the 
operating  system  to  maintain  information  vital  to  system 
control.  The  only  control  block  modification  required  to 
supoort  process  segmentation  was  the  PROC.  A  list 
containina  a  PROC  for  each  active  process  is  maintained  bv 
the  system.  In  UNIX/  a  P°0C  contains  the  bloc*  address  of 
the  UVECTOR  and  the  size  of  the  process  image  (which  aces 
not  include  shared  text).  In  SUMIX  ana  SSUNIX,  a  PPOC 
contains  the  block  aocress  of  each  of  the  orocess  segments 
ana  the  sizes  of  the  data  ana  s^acK  segments. 

Several  new  control  blocks  were  adaea  to  i  m  o  I  p  m  e  n  t  aata 
segment  alignment  within  a  shared  core  area.  S H w E M  defines 
the  upper  and  lower  bounds  of  each  shared  memc<~y  reaion. 
Svstem  shared  core  configuration  changes  reoui  r»  modifyinq 
the  entries  in  this  structure.  SHME^  is  usee  at  svstem 
initiation  time  to  initialize  two  other  shared  memory 
control  blocks.  A  SHAPE  contains  information  about  a 
particular  shared-memory  asset.  The  high  and  low  bounds  of 
the  region,  a  f 1 aa  inaicating  whether  or  not  the  region  is 
in   use   by  another  memo ry-sh a r i no  process/  and  another  f 1 aa 
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used  by  "  m  a  1  1  o  c  "  are  maintained  here.  A  S  h  R  M  A  P  is  a 
structure  which  contains  a  free  memory  map  for  each  of  the 
shared  reqions.  The  Taos  in  S H R M A p  were  configured  exactly 
like  the  other  system  free  maps  so  thev  could  he  maintained 
by  "mat  loc"  and  "mf  ree". 

C.   MEMORY  MANAGEMENT  MODIFICATIONS 

Adaotina  the  existing  UNIX  memory  management  routines  to 
perform  Drocess  segmentation  was  a  straightforward  problem: 
in  each  routine  that  cealt  with  a  process  imaae/  the  process 
imaae  was  managed  as  three  indeDendent  seqments  instead  of  a 
single  entity.  Although  simply  stated/  solving  this  oroolem 
required  many  hours  of  familiarization  with  existing  UNIX 
concepts/  and  modifying  several  hundred  lines  of  source 
code.  Details  of  these  modifications  are  not  included  here / 
but  are  contained  in  Apoendix  B.  Copies  of  system  source 
code  cannot  oe  included  in  this  thesis  due  to  UNIX  non- 
disclosure agreements.  However/  author i zee  UN  IX  User's  mav 
acquire  machine-readable  cooies  by  contacting  the  N'  a  v  a  1 
Postgraduate  School. 

0.   SWAP  SPACE  ALLOCATION  M00TFTCAT IONS 

owao  space  is  a  1  1  c  c  a  t  e  a  to  a  orocess  when  it  must  De 
swaoped  out  of  memory,  and  freed  wnen  the  process  returns  to 
memory.  A  mao  of  free  soace  on  the  svstem's  swap  device  is 
maintained  Dv  M  m  a  1  1  o  c  "  and  "mfree".  The  s  v  s  f  e  m  routine 
"swao"  is  used  ♦•  o  t  r  ar  s  f  e  r  data  oetween  memory  and  the   swao 
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device.  SUNTX  and  SSUNlX  processes  consist  of  three 
segments  that  are  i neeoenden t 1 y  established  in  main  memory. 
Moving  a  process  image  to  the  swao  device  requires  a  "swap" 
operation  for  each  segment.  Also/  when  shared  text  nnUst  oe 
established*  an  additional  "swap"  ooeration  is  involved. 
Actual  space  on  the  swao  device  is  allocated  in  a  conMouous 
block.  The  disk  address  of  the  process  is  the  aadress  of 
the  uVECTOR.  Data  (  i f  any)  and  stack  are  located 
immediately  following  the  UVECTHR.  Shared  fext  is 
separately  established/  and  retains  if  swao  space  until 
there  are    no  longer  any  live  orocesses  which  reauire  it. 

E.   SHARED  MEMORY  ALLOCATION  MODIFICATIONS 

The  basic  ideas  underlying  the  aesign  of  a  shared- 
segmentea  memory  manager  for  UNIX  (SSUNlX)  were  presented  in 
Chaoter  III.  Actual  oesion  work  was  started  after  SUMI*  was 
implemented  and  had  Demonstrated  satisfactory  performance. 
The  accroach  taken  in  the  develooment  of  SSUNlX  was  to  aad 
several  system  level  routines  to  oerform  the  shared  memory 
management  functions*  ana  thus  modify  exist ina  S  U  N I X  code  as 
little  as  cossible.  Three  new  system  routines  were  added: 
"ckmao"/  to  chec*.  the  User  free  memorv  map;  "shalloc"/  to 
allocate  a  otocpss's  data  segment  to  a  aiven  snared  core 
region;  and  "shfree",  to  free  a  process's  shared  core  asset. 
Svstem  calls  *or  User  proaram  interface  with  "shalloc"  and 
"snfree"  were  also  implemented.  From  a  User's  proaram/ 
"aetshr"    acauires   a   shared   core   asset/   and   "freeshr" 


^5 


releases  it.  A  brief  summary  of  each  new  routine  and  the 
other  modifications  maae  to  SUNIX  is  oroviaed  in  tne 
following  paragraphs.  Detailed  information  can  be  found  in 
Append  i  x  B, 

The  new  procedure  "c<man"  was  the  basic  primitive  used 
for  shared  core  allocation.  Its  function  was  twofold:  check 
the  User  free  memory  mao  to  determine  if  an  area  between  a 
given  high  and  lew  block  address  was  free/  and  tKen,  if  fhe 
area  was  freer  remove  it  from  the  free  man.  The  design  of 
this  procedure  orovided  an  interest ina  challenge.  Once  it 
was  determined  that  the  area  was  free/  several  Doundary 
alianment  conditions  h a <i  to  be  considered  in  order  to  remove 
it  from  the  free  memory  mao.  The  procedure  "sha'loc" 
performed  the  actual  a' location  and  assignment  of  a 
processes  data  seament  to  the  requested  sharea  core  area. 
It  also  locked  the  crocess  image  in  memory.  The  alcorifhm 
implemented  was  described  in  the  orevious  chanter.  In  order 
to  prevent  allocation  of  another  orocess  within  the  shared 
core  region  durina  the  shared  core  acauisition  by  "snal loc"> 
a  slight  modification  to  the  memory  management  primitive 
"malloc"  was  reouired.  A  orccess's  shared  memory  asset  was 
freed  by  "shfree".  In  addition  to  the  system  call 
interface/  tnis  routine  was  called  from  tne  "exit"  procedure 
to  ensure  that  a  process's  shared  core  was  releasea  af 
process  termination. 

Otner  modifications  to  SUN IX  included:  "main"/  to 
establish  shared  core  regions  ana  initialise  tneir 
respective  control  blocks;  and  "sysent"/  to   orovioe   svstem 


?6 


entry  points  for  the  System  calls   "getshr"   and   "freeshr". 

The   source  code  reauired  to  build  both  SUNTX  and  SSUNIX  can 

be  found  in  the  directory   /usr/sys.sunix   on   the   display 

processor's  file  system. 

F.   SUPPORT  PROGRAM  MOD TF TC A T TOMS 

One  supoort  proaram  modification  was  reauired  for  SUN  IX 
and  SSUNIX.  The  Shell  command  "os"  [113  disclays  certain 
information  about  active  orocess  status.  It  uses  the  P R 0 C 
list  to  acquire  t  ^  i  s  information  for  displav  at  the  U  s  e  r  '  s 
terminal.  Since  the  structure  of  the  P"0C  was  modified  to 
supoort  process  segmentation,  certain  variables  used  by  "os" 
were  invalidated.  Tn  particular,  the  address  ana  size  of  a 
process  imaae  in  UNIX  were  described  in  two  variables  in  the 
PROC.  In  SUNTX  and  SSUNIX,  five  variables  were  required: 
UVECTOR  address  (its  size  is  fixed  at  . 5 K  words),  data 
segment  address,  data  segment  size,  stack  seqment  address, 
and  stack  segment  size.  To  retain  the  display  format  used 
bv  "ps",  it  was  decided  that  all  five  of  these  attributes 
would  not  be  oresented.  Since  the  user  is  normally 
concerned  with  only  his  data  segment's  address  and  size, 
these  values  were  substituted  for  the  exist ina  values  in 
"os".  The  revised  version  of  this  routine  can  be  found  in 
/usr/sys.sunix  on  the  disolay  processor's  file  svstem.  The 
object  version  of  "os"  found  in  /bin  must  be  replaced  with 
the  revised  object  during  SUNTX  ana    SSUNIX  operation. 
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V.   EVALUATION  OF  PERFORMANCE 


A.   OVERVIEW 

As  stated  throunhcut  this  report/  completion  and  testing 
of  SUNIX  was  an  integral  part  of  this  thesis  ana  a 
prereauisite  for  the  development  of  S SUN  IX.  a  severe 
problem  with  the  SUNIX  memory  manager  had  prevented  its 
final  implementation.  This  problem  manifested  itself  in  an 
inability  to  assemble  certain  proorams.  Since  the  assembler 
is  usea  durina  a  oass  of  the  " C  "  compiler/  compilations  were 
also  affected.  Several  wee^s  af  the  outset  o  *  this  tresis 
project  were  reouirea  to  become  familiar  with/  debug  and 
test  SUNIX.  Once  familiar  with  the  concepts  of  system 
organization  and  memory  management/  Emery's  desicn  r  e  a  d  i  1  v 
supporteo  the  deougging  effort  at  nand.  Tne  oroblem  was 
eventually  found  and  corrected  in  tne  memory  management 
routine  "exec".  Development/  i mo  1 emen t at i on  and  testing  o* 
SSUNIX  followed.  Performance  of  SUNIX  and  SSUNIX  was 
evaluated  in  relation  to  UNIX.  Additionally/  tests  were 
conducted  which  demonstrated  the  capaoilitv  of  3 SUN  I  *  to 
perform  data  segment  allocation  and  deallocation  of  scared 
core. 
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B.   COMPARISON  WITH  UNIX 

The  method  chosen  to  compare  Derformanc?  of  UNIX,  SUN  IX 
and  SSUNIX  was  to  use  the  elaoscd  execution  rime  of  a 
standard  stream  of  processes  (benchmarks).  A  series  of 
benchmarks  was  run  to  determine  relative  oerformance  under  a 
variety  of  operatina  conditions.  Available  User  memory  was 
the  variable  used  to  establish  these  conditions.  Two 
benchmar<s  were  used:  a  monoproaramming  benchmark?  B £ N C H 1  * 
and  a  multiprogramming  benchmark,  B E N C H 2 •  These  benchmarks 
are  essentially  identical  to  those  used  bv  Emery  in  ^  i  s 
testing  of  PSUNIX.  Poth  BENCH1  and  REMCH2  contain  the  same 
sequence  of  UNIX  commands.  These  commands  are  documented  in 
Ret.  11.  APPFNDI*  C  contains  benchmark  listings.  The 
computer  system  used  for  the  tests  was  the  multiuser  side  of 
the  laboratory  configuration  shown  in  Figure  1.  a  single- 
user  environment  was  established  with  only  the  console  on- 
line. The  ourpose  of  this  was  to  prevent  the  introduction 
of  an  added  variaole  in  benchmark  performance  due  to 
processes  aener at ed  by  other  Users  on  the  system.  The  swao 
soace  and  file  system  used  were  located  on  RP05  cisk  units 
[3J  . 

Table  I  presents  the  results  of  benchmark  tests  for 
UNIX,  SUNIX  and  SSUNTX.  Available  User  memorv  space  was 
varied  to  evaluate  oerformance  over  a  wide  range  of  svstem 
configurations.  Tim i no  data  was  obtained  by  using  t^e  UNIX 
"time"  command  till.  Processes  run  under  control  of  "time" 
are   clocked   bv   samolina  processor  state  at  the  rate  of  &0 
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Hz.  "Real"  time  reflects  the  total  elapsed  time  for  the 
process  and  is  reported  to  the  nearest  second.  "User"  time 
is  the  time  scent  in  the  Use'"  state  (ie.  executing  the 
User's  proaram  instructions)  and  is  reoorted  to  the  nearest 
tenth  of  a  second.  " Sys"  time  is  the  time  spent  during  the 
execution  of  operating  system  supervisory  instructions  and 
is  reported  to  the  nearest  tenth  of  a  second.  The 
difference  between  "real"  time  and  the  sum  of  "user"  end 
"sys"  times  indicates  the  amount  of  processor  idle  time. 
Idle  time  generally  reflects  the  amount  of  time  spent  on 
asynchronous  I/O  operations. 

In  addition  to  benchmark  test ina  in  a  single-user 
configuration,  SUNTX  was  run  for  a  full  day  of  multiuser 
program  development.  The  svstem  was  fullv  configured  (Fig. 
1)  and  moderate  to  heaw  system  utilization  was  noted. 
Svstem  Users  were  asked  to  report  any  oroblems  to  the 
laboratory  staff.  No  system  failures  occurred  and  no 
problems  were  reoortec.  This  test  orovidea  an  excellent 
indication  of  prooer  svstem  ooeration  as  uieH  as  the 
transparency  of  the  memory  management  method  to  svstem 
Users . 

C.   SHARED  MEMORY  ALLOCATION 

Testing  of  data  segment  allocation  to  sharea  core  was 
performed  on  the  o  i  s  e  1  a  y  processor.  The  system  was 
configured  with  a  single  terminal  and  the  svstem  console. 
Swao   soace  and  the  file  system  were  maintained  on  P  P  0  5  disk 
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units.  To  demonstrate  the  oerformance  of  SSUMIX,  it  was 
necessary  to  develop  a  method  for  displaying  certain 
relavent  system  information.  Three  items  were  reauiredt  the 
location  of  a  process's  data  segment  in  memory,  the  state  of 
the  User  free  memory  n-ao,  and  the  state  of  each  of  the 
shared  memory  maps.  This  data  best  indicated  the  shared 
memory  allocation/deallocation  orocess.  A  system  call 
("shtest" )  was  developed  to  d  i  s  o  1  a  v  this  information  at  the 
display  processor's  console.  Several  test  orogra^s  which 
included  shared  core  allocation  requests  ("getshr")  and 
shared  core  deallocation  requests  ("freeshr")  in  various 
sequences  were  develooed.  "Shtest"  was  included  in  these 
proorams  to  disolay  the  required  information  after  each 
shared  core  ooeratien.  This  aporoach  proved  invaluable  in 
the  debugging  and  refinement  of  SSUMIX. 

0.   ANALYSIS  OF  RESULTS 

The  results  shown  in  Table  T  clear! v  indicate  that  the 
performance  of  UNIX,  SUNIX  and  SSUNIX  are  nearly  identical. 
No  statistical  analysis  was  performed  on  these  results/  but- 
earlier  work  [6]  indicates  that  the  sampled  data  may  have  a 
standard  deviation  of  as  much  as  8  percent  on  identical 
benchmarks  run  several  times  on  the  same  system.  System 
supervisory  times  ("SYS")  under  SUNIX  and  SSUMIX  were  found 
to  be  sliahtlv  better  than  U  W I  Y  in  some  cases.  This  is  a 
surer i sing  result  in  lioht  of  the  more  complex  memory 
management    function    with    orocess    seamen t a t i on .    The 
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disadvantage  related  to  increased  swaoping  overhead  did  not 
aopear  to  degrade  overall  system  performance.  A  probable 
explanation  for  this  result  is  an  offsetting  performance 
improvement  due  to  independent  dynamic  growth  of  aata  and 
stack  segments.  These  factors  were  discussed  in  Chapter 
III.  SSUNIX's  oerformance  in  a  t*  u  1  t  i  ported  memory 
environment  was  validated.  The  tests  performed  usina 
"shtest"  indicated  that  shared  core  allocation  and 
deallocation  of  a  orocess's  data  was  prooerly  managed. 
Additionally/  since  SSUNIX  benchmark  timing  data  was  so 
nearly  identical  to  that  of  the  other  systems^  the  data 
segment  alignment  capaOilitv  had  no  sianificant-  effect  on 
system  oerformance. 
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VI.   CONCLUSIONS  AND  RECOMMENDATIONS 


The  primary  goal  of  this  thesis*  an  extension  of  the 
UNIX  memory  manager  to  provide  data  segment  alianment  with 
svstem  protection,  was  successfully  implemented  in  the  form 
of  SSUNIX.  Performance  results  were  encouraging.  However, 
before  the  benefits  of  this  svstem  c  an  be  fully  real i  zeu* 
other  related  develoDment  work:  in  the  Signal  Processing  and 
Display  Laboratory  is  necessary.  This  chapter  provides 
recommendations  directed  toward  the  development  o*  a  total 
system  support  oackage  for  the  laboratory's  display 
processor.  Also  included  is  a  recommendation  *or  further 
research  in  the  area  of  segmented  memory  manaaement. 

A.   CONTROLLED  m£mopy  ALLOCATION 

Several  different  operatina  systems  for  the  display 
processor  have  been  developed  to  crovioe  support  for  special 
peripheral  devices.  Two  of  these  systems  were  designed  to 
provide  process  alicnment  in  a  particular  area  of  memory: 
one  for  CSP  125  processes/  and  another  for  v  0-  processes. 
The  existence  of  a  number  of  different  operating  systems, 
each  with  a  particular  application,  causes  a  sianificant 
confiauration  control  problem  in  the  laboratory.  Since 
SSUNIX  was  designed  with  these  specific  applications  in 
mind,   a  direct  implementation  of  this  system  on  tne  displav 
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processor  would  simplify  the   system   configuration   control 
prob 1  em . 

b.   MULTIPROCESSOR  INTERFACE 

As  indicated  in  Figure  l>  tHe  PDP-11/34  slave  orocessor 
is  presently  treated  as  an  inaependent  system  oeriohera). 
THe  design  work  done  by  Grav  (51  Has  not  yet  been  tested  in 
tHe  multiprocessor  environment  for  which  it  was  int"enaea. 
Additionally*  the  hardware  interfaces  for  the  32K  word 
shared  core  area  and  the  VG  di  sol  ay  device  have  not  ceen 
implemented.  The  dashed  lines  in  Figure  1  deoict  the 
configuration  reguired  to  complete  the  multiprocessor 
interface.  Once  this  is  doner  implementation  of  the  slave 
processor's  operating  system  ana  integration  of  SSUNIX  into 
the  multiprocessor  environment  could  follow.  Investigation 
of  the  communication  reoui  rements  and  protocol  between  the 
master  processor  and  the  slave  Drocessor  is  reguired.  Also* 
the  inter-orocessor  graphics  supoort  oackage  desiqnea  by 
Visco  i\  2.)  must  oe  reviewed  to  ensure  prooer  interface  with 
the  "getshr"  and  "freesnr"  system  calls  of  SSUNIX.  Only 
slight  modification  to  SSUNIX  would  oe  reauirea  tc  establisH 
this  interface.  One  sugaested  approach  is  to  imolement 
Visco's  "rtime"  and  "nonrtime"  system  calls  in  SSUNIX  to 
perform  the  functions  as  "getshr"  and  "freeshr".  T  H  i  s 
aoproach  has  the  advantaoe  of  reoui rinq  only  si  mole 
modifications  to  S  S ' '  N I X  and  no  modifications  to  the  graphics 
interface  routines.   Another  rossioi  1  i  tv   is   modifying   the 


U5 


Vector  General  routines  to  scaui  re  sharea  core  via  "getshr", 
and  release  it  via  "freeshr". 

C.   INVESTIGATION  OF  SWAPPING  POLICIES 

The  disadvantage  of  seamented  memory  management 
requiring  a  greater  numoer  of  cooy  operations  for  nrocess 
swaopina  has  been  stated  previously*  An  interesting  topic 
for  further  invest iaation  is  the  development  of  an  extension 
to  S3 UNIX  (or  SUNIX)  which  imolements  swaopina  on  a  segment 
Oasis.  Mod i f i cat i ens  to  SSUNIX  to  supoort  this 
investigation  would  involve  revision  of  the  orocess 
scheduling  routine  "schea"»  the  Drocess  memory  allocation 
routine  "cral loc%  the  routine  for  swapDing  processes  out  of 
core»  "xswapM/  and  the  routine  for  swapping  processes  into 
core  r  "orswap".  It  is  contended  that/  althouah  the  memory 
management  function  will  be  slightly  more  complex,  the 
actual  changes  reauired  to  existing  routines  will  not 
degrade  system  performance.  In  fact >  since  swapping  is  a 
significant  factor  in  system  overhead*  an  optimum  swaopina 
policy  should  enhance  overall  performance. 
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APPENDIX  A:   CONTROL  BLOCK  MODIFICATIONS 


A.  DOCUMENTATION  FORMAT 

This  apoendix  is  intended  to  be  used  with  a  copv  of  the 
source  code  for  UNIX  Version  6),  SUNIX  and  SSUNTX.  It 
contains  documentation  of  t^e  modifications  made  to  U^'IX 
control  blocks  to  implement  the  two  new  segmented  systems. 
Source  code  for  these  control  blocks  in  the  UNIX  form  is 
found  in  the  directory  /usr/svs,  Source  code  for  the 
modified  versions  can  be  found  in  the  directory 
/us r/sys . sun i x  on  the  disolav  orocessor's  file  svstem.  The 
format  of  this  apoendix  and  some  of  the  documentation 
contained  herein  are  identical  to  APPENDIX  A  of  Ref.  4 . 
Each  control  block  is  described  under  an  uDper  case  roman 
letter.  The  control  block  name  is  followed  by  the  source 
code  file  in  which  it  is  found.  An  overview  and  a 
description  of  sionificant  data  elements  is  provided  for 
each  control  block. 

B.  SHRMAP,  share. h 

1  .   Overview 

SHR^AP  is  a  structure  containina  N SHARE  f re°  memorv 
maps  of  shared  core  regions.  N SHARE  is  a  tunable  parameter, 
also  found  in  "share.h",  which  soecifies  the  number  of 
shared   core  areas  in  the  system.   This  control  bloc*  is  not 
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founa  in  UNIX  or  SUNIX.  Each  map  in  SHPMAP  is  an  inteaer 
array  containing  the  physical  block  number  ana  size  of  an 
unallocated  memory  area.  The  maps  are  sorted  in  physical 
block  number  order.  This  con f i aurat i on  is  identical  to 
COREMAP  and  SWAPMAP.  Documentation  of  "malloc.c"  in 
APPENDIX  B  describes  the  memory  Tianaqe^en  t  primitives  which 
manipulate  the  free  memory  mans. 

2.   Significant  Data  Elements 

a.   int  shmao  (5HMAPSIZJ 

This  is  the  soec i f i c a t i on  for  a  single  shared 
memory  map  contained  in  SHp^AP.  SHMAPSI7  is  a  tunable 
parameter  defined  in  "share.h". 

b  .   char  *m*-s  i  ze 

This  is  t^e  size  of  the  ^ree  area  in  64-bvte 
clocks. 


C  .   c  h  a  r  *m«-add  r 

This   is   the   ohysical  block  number   of 

beginning   of   the   free  area     in  the  snared  core  reaion. 

this  value  is  zero*  it  marks  the  end  of  the  map. 


1-  he 
If 


C.   SHARE,  share.h 

1  .   Overview 

A  SHAPE  contains  certain  control  information  aoout  a 
shared  core  region.  There  is  one  of  these  control  dIocks 
for  each  of  the  N SHARE  regions.   Share   is   not   define^   in 
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UNIX  or  SUNIX. 

2  .   Significant  Data  Elements 

a  .   i  nt  basador 

This  is  the  physical  block  number  of  the  base  of 
the  shared  core  region  in  memory. 

b  .   i  n t  hi  addr 

This  is  the  physical  block  number  of  the  top  of 
the  shared  core  region. 

c  .   char  nuse  f 1  a 

This  is  a  flaa  which  indicates  that  the  shared 
core  region  is  in  use  by  a  resident  memory-sharing  process, 
further  details  on  its  use  are  nrovidea  in  apoenaix  Q  under 
the  documentation  of  "  s  h  a  1  1  o  c  .  c  "  . 

a.   char  ckf 1 g 

This  is  a  flag  which  indicates  that  no  orocesses 
are  to  be  allocated  memory  soace  within  the  bounds  of  the 
shared  region.  Its  use  in  "mallocO"  is  documented  in 
APPENDIX  B. 

0.   PRUC,  proc.h 

1  .   Overview 

One  P  "  0  C  is  allocated  for  each  active  process  in  the 
svstem.  The  PROC  exists  for  the  life  o*  the  orocess.  PROCS 
a^e  maintained  in  an  array  called  "oroc"  which  is  M  P  R  0  C  in 
size.   Tnis  array  is  cerrnanently  resident  in  main  memorv  and 
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contains  all  cer    orocess  information  which  cannot  be  swapoed 
out  of  main  memory. 

2.   Significant  Data  Elements 

a.   char  o«-  f  1  ag 

This  is  a  word  of  flaas.   Bit  0  of  this  word  is 

the   SLOAD   flag.    If  it  is  set/  the  process  is  resident  in 
main  memory.   Bit  1  is  the  SLOCK  flag.   If  it   is   sef  /   the 

process   is  locked  in  memory  and  mav  not  be  swaopea  out.  In 

S S U N I X ,     this  bit  is  set  to  Iock  memorv-sharinq  processes  in 

memory.    Bit  2       of   this  word  is  the  SSWAP  flag.   If  it  is 
set/  the  process  is  oeing  swapped  out. 

D  .   l  nt  p«-adar 

This  variable  is  oresent  only  in  UNIX.  If  the 
process  is  resident  in  main  memory*  it  is  the  physical  block 
number  of  the  process's  UVECTOR.  If  the  orocess  is  swapped 
out/  it  is  the  swap  device  block  number  of  the  swapoed 
i  maae . 

c  .   i  nt  p<-s  i  ze 

This  venaole  is  oresent  only  in  UNIV.  It  is 
the  size  of  the  process's  swappable  imaae  in  64-pyte  blocks. 

d.   int  p*-t  ex  t  p 

This  is  a  pointer  to  the  process's  TEXT.  If  trie 
value  is  zero/  the  orccess  do^s  not  have  shareo  text. 
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e.   int  p+-caodr 

This  variable  is  present  only  in  5 UNIX  and 
SSUNIX.  It  is  the  main  memory  physical  block  number  of  the 
process's  UVECTOR  while  the  process  is  in  memory. 

f  .   int  p*-dadc  r 

This  variable  is  oresent  only  in  SUN IX  and 
SSUNIX.  It  is  the  swap  device  block  number  of  the  process's 
swao  space.   If  it  is  zero,  the  process  has  no  swap  SDace. 

g.   int  p«-ds  i  ze 

This  variable   is  present   onlv   in   SUN  IX   and 

SSUNIX.    It   is   the   size  of  the  process's  data  segment  in 
t>4-by  t  e  b  1  ocks  . 

h  •   int  p«-ss  i  ze 

This  variable  is  present  only  in  SUN  IX  and 
SSUNIX.  It  is  the  size  of  the  process's  stack  in  64-bvte 
b 1 ocks . 

E.  '  UVECTOR,  user.h 

1.   Overview 

The  structure  "user"  is  referred  to  as  the  UVECTOR. 
One  of  these  structures  is  part  of  each  swapcable  process 
image.  The  UVECTOR  contains  all  process  data  that  is  not 
needed  when  the  process  is  not  in  control  of  the  processor. 
When  the  process  is  in  control  of  the  processor,  its  UVECTOR 
resides  at  a  fixeo  location  in  the  ooeratinc  system  oata 
soace . 
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2..       Significant  Data  Elements 

a  .   i  n  t  u«-u  i  sa  Lib! 

In  UNIX  this  array  contains  the  b^-byte  block 
di so  I acement s  from  the  sfart  of  the  reaion  of  the  orocess's 
data  and  stack  caaes.  In  SUNTX  and  SSUNIX  this  array  i  <?  not 
used . 

b.   int  u «-  u  i  s  d  [  1  b  1 

This  arav  contains  the  prototypes  of  the 
process's  user  I-space  an6  0-space  page  descriptor 
regi  s t  e  r s  . 

c  .   int  u«-t  s  i  ze 

This  is  the  size  of  the  orocess's  shared  text 
segment  in  ba-byte  blocks. 

d  .   int  u*-as  i  ze 

This  is  the  size  of  the  process's  data  seament 
i  n  ba-py t  e  blocks. 

e.   int  u*-ss  i  ze 

This  is  t^e  size  of  the  process's  stac<  seament 
in  b4-by  t e  blocks. 
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I.   APPENDIX  8:   ME^OPY  MANAGEMENT  MODIFICATIONS 


A.   DOCUMENTATION  FORMAT 

As  with  APPENDIX  A/  this  apoendix  is  intended  to  be  used 
with  a  cody  of  the  source  code  for  UNIX,  SUMIX  and  SSUNIX. 
It  contains  documentation  of  the  modifications  to  UNIX 
memory  management  functions  which  were  feaui  red  to  produce 
the  two  segmented  systems.  The  format  used  here*  and  some 
of  the  document  at i on ,  is  identical  to  APPENDIX  B  of  pef.  4. 
UNIX  source  code  is  aiviaed  into  several  files  containino 
related  blocks  of  code.  The  functions  documented  in  this 
aopendix  are  qrouoed  under  an  uooer  case  roman  letter  and 
the  name  of  the  file  in  which  they  are  found.  Each  function 
in  each  file  is  labeled  with  an  arabic  number.  The 
documentation  of  each  function  is  divided  into  four 
suosect  ions:  oarameters,  functional  description,  returned 
values,  and  error  ccncitions.  The  files  containing  the  UNIX 
functions  are  founa  in  the  directory  /usr/sys/ken.  Tne 
files  containing  the  modified  versions  of  the  functions  for 
SUN  IX    and    SUN  IX    are  found     in     the     directory 

/usr/sys.sunix/Wen  on  the  display  processor  file  system.  In 
this  directory/  those  files  which  contain  modifications 
SDecific  to  SSUNIX  are  nref  ix<>d  with  tne  letters  "  s  h  "  . 
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B .   main.c 

1  .   mainO 

a .   Paramet  ers 

This  function  has  no  Darameters. 

o.   Functional  Descriotion 

This  is  the  operatinq  system  initiation 
function.  Physical  memory  configuration  is  determined/  User 
memory  space  is  cleared/  and  all  system  free  ^aDS  ar^ 
initialized.  Process  0  and  Process  1  are  created.  In 
SSUNIX,  the  soec i f i ca t i on  array  for  shared  core 
confiquraton,  "shmem",  is  found  in  the  file  "main.c".  This 
function  utilizes  "shmem"  to  initialize  the  SHR^APs  and 
SHAREs  described  in  APPEN0Iy  4.  Shared  core  configuration 
changes  are  managed  by  modifyina  the  entries  in  "shmem". 
Upon  completion  of  initiation  tasks,  the  process  schedulino 
routine,  "sched"/  is  called.  "Sched"  then  runs  until  the 
ooerating  system  crashes  or  is  otherwise  terminated. 

c.   Returned  Values 

This  function  does  not  return. 

a.   Error  Conoi  t ions 

An  error  occurs  if  the  system  cloc^  cannot  be 
establ  i  shea . 
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2.   est?Dur(nt »ndf nSf sen) 

a  .   Paramet  ers 

The  first  three  parameters  are  the  sizes  of   the 

current   Drocess's   shared   text >  data  and  stack  seqments  in 

64-byte  dIocks.   The  last  parameter   is   a  separation   flag 
that   is   set   if  the  process  has  solit  instruction  ana  data 

spaces.    The   current   process's   U VECTOR  is   an    implied 
pa  rame t  e  r  . 

D  .   Functional  Descriotion 

This  function  first  checks  the  validity  of  its 
arguments.  It  loads  the  Prototypes  of  the  memory  management 
page  descriptor  registers  into  the  arrav  u«-uisd(J  found  in 
the  current  UVECTOR.  In  UNIX  it  also  loads  page  start 
displacements  measured  in  blocks  from  the  beginning  of  the 
region  or  text  into  the  array  u«-uisaU  found  in  the  current 
UVECTOR.  The  array  u«-uisatl  is  not  loaded  in  SUNTX  and 
SSUNI*.  Its  values  are  are  not  reguired  since  the  values  of 
the  parameters  are  placed  in  the  variables  u  <- 1  s  i  z  e  ,  u  *-  d  s  i  z  e  , 
u«-ssize,  and  u*-sep  in  the  current  UVECTOR.  In  all  versions, 
"sureg"  is  called  to  load  the  actual  memorv  management 
regi  st  er s . 

c.   Returned  Values 

If  the  oarameters  are  invalid,  minus  one  is 
returned;  otherwise,  a  zero  is  returned. 
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d.   Error  Concisions 

The  minus  one  return  indicates  an  error   to   the 


ca  1  1 e  r . 


5.   c ks i ze ( n t / nd / n s , sep ) 

a  .   Parame t  ers 

The    parameters    are  the    same     as     for 

Hestabur(nt»nd»nsrsep)"  described  above. 

o.   Functional  Description 

This  function  is  present  onl v  in  S  U  N I X  and 
S  S  U  N  I X  .   It  checks  its  oarameters  to  see  if  they  are    valid. 

c.  Returned  Values 

If  the  oarameters  are  invalid*  a  minus  one  is 
returned.   Otherwise/  a  zero  is  returned. 

d.  Error  Conditions 

A  minus  one  return  indicates  an  error  to  tne 
ca 1 1 er . 

C .   ma  1  1 oc  .c 

1 .   ma  1  1 oc (mp , s  i  ze  ) 

a .   Parame t ers 

The  parameters  are  a  oointer  to  a  free  memorv 
map  array  and  the  size  in  oloc<s  of  the  region  to  be 
allocated  from  the  ^ac. 
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o.   Functional  OescriDt ion 

This  function  allocates  SDace  in  main  memory  and 
on  the  swap  device.  If  User  free  memory  soace  is  to  be 
allocated*  the  first  parameter  must  point  f  o  C  0  R  £.  ^  A  P  *  and 
the  size  must  be  specified  in  6^-hyte  blocks.  If  swao  space 
is  to  be  allocated*  the  first  parameter  must  point  to 
SWAPMAP,  and  the  size  is  soecified  in  256-word  sectors.  If 
shared  core  is  to  be  allocated*  the  first  parameter  must 
point  to  a  S  H  R  ^  A  P  *  and  the  size  is  soecifiea  in  6  4  -  d  v  t  e 
blocks.  In  S  S  U  N I X  only*  this  function  checks  the  global 
flag*  "sharflg"*  if  COREMAP  is  soecified.  If  "sharfla"  is 
set*  the  function  must  then  check  the  " ck  f I  a "  in  each  SHARE 
before  allocatina  soace  in  COREMAP.  I  *  a  "ckflg"  is  set*  a 
free  area  which  incluces  anv  Dart  of  that  particular  shared 
region  will  not  be  allocated. 

c.  Returned  Values 

If  allocation  is  successful*  this  function 
returns  the  physical  block  numoer  of  the  base  of  the 
allocated  area.       Zero    is  refumea  if  space  is  unavai  lade. 

d.  Error  Conci  t  ions 

A  zero  returned  value  indicates  allocation 
failure  to  the  caller. 

2.   m f ree f mo  * s i ze * aa ) 
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a .  Pa  r ame t  ers 

The  first  two  parameters  are  the  same  as  those 
for  "  m  a  1  1  o  c  "  described  above.  The  third  parameter  is  a 
physical  block  number  of  an  area  o*  main  memory  or  swao 
soace . 

b.  Functional  Hescriotion 

This  function  frees  the  soecifiea  area  in  the 
soacified  free  m  a  o  .  If  the  first  parameter  ooints  to 
CORE MAP,  the  area  is  freed  in  the  User  free  memcrv  map.  If 
the  first  parameter  points  to  SWAP MAP,  the  space  is  freed  in 
the  free  mao  of  the  swao  device.  In  S S U N I X  o  n  1  v  ,  if  the 
first  parameter  points  to  a  SHR^AP,  the  area  is  freed  in  the 
map  of  that  particular  shared  core  region.  Sizes  are  in 
64-byte  blocks  if  CCRFMAp  0r  a  SHRMAP  is  specified,  and  in 
256-word  sectors  if  S  to  A  P M  A  P  is  specified. 

c.  Returned  Values 

The  value  returned  by  this  function  is  not 
chec  ked. 

d.  Error    Concitions 

This  function  has  no  error  conditions. 

3.   c  kmap ( r 1  a  >  rh  a ) 

a.   Parameters 

The  parameters  are  the  low  address  and  high 
address  in  ohvsical  Dlock  numbers  of  a  reaion  of  main  memorv 
soace.   CORF MAP  is  an  implied  parameter. 
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b.   Functional  Description 

This  function  is  present  in  SSUNIX  only.  It 
checks  COREMAP  to  determine  if  the  specified  region  of  main 
memory  is  free.  Tf  the  area  is  freer  it  is  removed  from 
CORE MAP  and-  the  map  is  rebuilt  to  reflect  the  removal.  In 
order  to  rebuild  the  m  a  o ,  several  boundary  alignment 
conditions  are  checked.  The  position  of  the  free  area 
boundaries  in  relation  to  the  boundaries  specified  in  the 
parameters  determines  the  algorithm  used  to  sort  and  rebuild 
the  map.  This  function  is  used  in  conjunction  with  the 
shared  core  allocation  function,  "  s  h  a  1  1  o  c  "  ,  descriced  below. 

c  .   Returned  Values 

L^  the  specified  area  is  free  and  was  removed 
from  CQPEMAP,  a  one  is  returned.  If  anv  oart  of  the  area  is 
in  use,  a  zero  is  returned. 

d.   Error  Conditions 

This  function  nas  no  error  conoitions. 

4.   sha 1 1 oc ( scname ) 

a  .   Pa  rame  ters 

The   parameter   is  an  inteoer    value    which 

specifies  a  particular  scared  core  region.  The  PRCCs  and 
TEXTs  of  all  processes,  the  current  process's  U VECTOR,  the 
SHAPEs,  and  the  SHRMAPs  are    all  implied  parameters. 
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b.   Functional  Oescriot  i  on 

This  function  is  oresent  only  in  SSUNIX.  It- 
performs  the  shared  cere  allocation  process  bv  acauirina  the 
region,  reserving  it  for  memory-sharing  orocesses,  and 
positioning  the  caller's  data  segment  in  it.  The  function 
first  checks  the  validity  of  its  input  araument.  The 
"  c  k  f  1  q  "  for  the  specified  region  and  the  global  "sharflg" 
are  set  to  oreven*  allocation  of  soace  within  the  region 
during  the  acquisition  process.  To  ensure  that  the  calling 
process  is  not  within  the  oounds  of  the  shared  core  area 
that  it  is  trying  f  o  acquire,  it  is  swapped  cut  of  memory 
using  "ceswap".  Since  "  m  a  1  1  o  c  "  will  not  allocate  space 
within  the  region,  when  the  process  returns  to  memory  it 
will  not  interfere  wifh  its  own  acauisition  process.  The 
"nuseflg"  of  tne  shared  core  area  is  checked  to  determine  if 
the  area  has  been  previously  acquired  and  reserved  for 
sharing.  If  the  area  has  oeen  reserved,  the  caller's  data 
segment  is  allocated  in  the  SHRMAP  and  tnen  copied  to  *r,e 
allocated  space.  If  the  area  is  not  reserved,  "ckmao"  is 
called  to  determine  if  it  is  free.  If  it  is  not  free*  the 
P  R  0  C  s  are  scanned  to  find  Drocesses  with  seaments  in  the 
area .  Interferinq  orocesses  are  swapDed  out  of  memorv  until 
the  region  is  free.  "  C  k  m  a  p  "  oerforms  the  actual  reservation 
process  oy  removing  the  region  from  COREMAP.  The  caller's 
data  segment  is  then  allocated  in  the  S  H  R  m  a  p  and  cooied  to 
the  allocated  scace.  In  anv  case,  after  the  orocess's  data 
segment  has  been  copied  to  the  region,  t^e  process  imaae  is 
locked  in  main  memory  by  setting  the  ^LOCK  f ] ag  in  the  PROC. 
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c  .   Returned  Va 1 ues 

If  the  shared  core  allocation  process  is 
successful/  the  physical  block  number  of  the  base  of  the 
caller's  data  segment  is  returned.  If  unsuccessful,  a  minus 
one  is  re t  u  rned . 

d.   Error  Conoi  t ions 

The  minus  one  r°tum  indicates  an  error  to  the 
caller.  This  value  can  result  from  one  of  two  error 
conditions:  improoer  inout  parameter,  or  failure  to  allocate 
the  process's  data  seament  fo  the  shared  core  region. 

5  .   sh  f  ree ( c  ) 

a .   Pa  ramet e  r s 

The  oarameter  is  a  oointer  to  the  calling 
process's  PRQC.  The  SHAREs  and  SHPMAPs  are  imDlied 
parameters . 

d.   Functional  Hescriotion 

This  function  is  oresent  only  in  SSUNIX.  It  is 
used  to  free  the  caller's  shared  core  asset.  If  first 
checks  f o  see  if  the  caller  is  a  memory-sharing  process.  If 
so,  that  process's  data  segment  is  deallocated  in  the  S  H  R  M  A  P 
of  the  region  that  it  occupies.  If  there  are  no  other 
memo r y -sh a r i no  processes  remaining  in  the  arear  it  is  freed 
in  C0REMAP  and  the  caller's  imaae  is  unlocked.  If  any 
memory-sharina  processes  remain,  the  caller's  imaae  is 
unlocked  and  swapoed  cut  of  memory.  In  this  case,  the  space 
occupied   bv   the  data  seament  is  not  freed  in  C0REMAP  since 
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the  area    must  remain  reserved. 

c.  Returned  Values 

The  values  returned  bv  this  function  are  not 
chec  iced . 

d.  Error  Conditions 

This  function  has  no  error  conditions. 

D  .   s  i  g  .  c 

1  .   cored 

a .  Pa  rame  t  e  rs 

The  current  process's  UVECTHR,  PRQC,  TEXT  and 
address  soace  are    implied  parameters. 

b.  Functional  nescriotion 

This  function  creates  a  memory  image  of  the 
current  orocess's  UVECTOR,  data/  ana  stac<.  In  UNIX  this 
function  uses  "estabur"  to  redefine  the  process's  virtual 
address  space  ana  make  the  data  and  stack  contiguous.  It 
then  writes  the  aata  and  stack  in  one  outout  operation.  In 
SUNIX  and  3SUNIX  this  is  imoossible  because  the  data  and 
stack  may  not  be  chysically  contiguous.  Two  output 
ooerations  are  reaui  rea?  one  for  the  data  and  one  for  the 
stack.  If  an  error  occurs  during  an  outout  ooeration»  an 
indication  is  left  in  u<-uerror  in  the  UVECTOR  of  the  current 
process . 
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c  .       Ret  urned    Va  1  ues 

This  function  returns  zero  if  successful  and  one 
if  an  outout  error  occurs. 

d.   Error  Concitions 

The  one  return  indicates  an  error  to  the  caller. 

2. .   grow  (  sp  ) 

a.   Parameters 

The   parameter   is   the   value   of   the  current 

process's  User  stack  co inter.   The  current  Drocess's  U VECTOR 
and  PROC  are    imolied  carameters. 


0.   Functional  Descriot ion 

This  function  is  called  asynchronously  when  the 
current  process's  stack  attemDts  to  expand  byond  the  space 
allocated  for  it.  This  function  calculates  the  number  of 
blocks  that  the  stack  must  be  increased,  validates  the  new 
stack  size,  and  acquires  the  memory  that  is  needed.  In 
UNIX,  "expand"  is  called  to  establish  the  new,  laroer 
address  soace  for  the  entire  orocess  image.  In  3UNTX  and 
S  S  U  N  I  X  ,  this  function  attemots  to  acquire  the  needed  space 
by  in-core  excansion  cf  the  stack  segment.  I*  unsuccessful, 
it  calls  "ceswao"  to  acouire  the  soace  bv  swaooi^g.  If 
successful,  it  cooies  the  old  stack  to  the  new  soace  and 
frees  the  old  memory.  In  all  versions  the  newly  acauired 
scace  is  cleared  and  "estabur"  is  called  to  reload  the 
memory  manaoement  regisfers. 


c .   Returned  Va 1 ues 

This   function   returns   a    zero 
unsuccessful  and  a  one  if  if  is  successful. 


if    it 


i  s 


d.   Error  Concitions 

A  zero  return  indicates  an  error  to  the  caller. 


£  .   s  1  p  .  c 


1 .   schea ( ) 

a .  Pa rame  t  e  r s 

The  PROCs  and  T  E  X  T  s  o  *  all  orocesses  are  irnolied 
parame t  ers . 

b.  Functional  Oescriotion 

This  •'unction  searches  *or  swapoed  out  processes 
that  "deserve"  t"  o  be  returned  to  memory.  it  selects  the 
most  "deserving"  orocessl  acauires  space  *  o  r  it  bv  swacpina 
out  other  processes  if  necessary;  and  returns  it  to  main 
memory.  In  SUNTX  and  SSUNIY  two  new  functions  are  useo: 
"oralloc"  to  acauire  main  memory  for  the  process*  and 
"orswap"  to  swao  it  ir. 

c  .   Returned  Values 

This  function  does  nof  return.  It  is  the  basic 
instruction  loop  for  Process  0.  It  goes  to  sleep  ana  is 
reawakened    a  0  o  u  t  once  per  second  by  the  clock  function. 
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d .  •  Error  Conditions 

In  UNIX,  if  a  swao  incut  or  outout  error  occurs, 
the  messaqe  "swap  error"  will  be  sent  to  the  console  and  the 
system  will  crash.  In  SUNIX  and  SSUNIX,  the  swap  ooerations 
occur  in  "prswac"  so  ro  error  messaoes  arf*    aenerated  here. 

2. .   neworoc  (  nrp) 

a  .   Pa  rame t  ers 

The  parameter  is  a  pointer  to  a  P°0C  to  oe 
estaolisheo  for  a  child  process.  The  current  Drocess's 
UVECTOR,  PROC,  and  TE*T  are     implied  parameters. 

b.  Functional  OescriDtion 

This  function  creates  an  exact  duplicate  of  the 
current  process  as  a  child  of  the  current  process.  It  *irst 
manes  the  aoprooriate  entries  in  the  child  and  oarent  PROCs 
and  in  the  TEXT  if  ore  exists.  It  then  attempfs  to  acauire 
memory  for  the  child  process.  If  it  is  successful,  it 
simply  copies  the  parent's  image  to  the  new  memory.  Tf  it 
fails,  it  swans  out  a  coov  of  the  parent  to  be  returned  to 
memory  as  the  chila.  In  SUN  IX  and  SSUNIX,  a  new  function, 
*  d  r  a  1  1  o  c  "  ,  is  used  to  attemot  to  acauire  memorv  for  the 
child. 

c.  Returned  Values 

This  function  returns  zero  to  the  parent 
process.  The  return  to  the  child  does  not  come  from  this 
function,  but  from  the  scheduling  function  "  s  w  t  c  h  "  .  The 
chila   can   identify   itself   as   the   child  because  "swtcn" 
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returns  a  one  to  it.   This  is  one  of  the  most  important   and 
subtle  ohenonena  in  UN  IX. 

d.   Error  Concisions 

If  the  PRCC  pointed  to  by  the  parameter  is 
already  allocated  to  an  active  process/  the  message  "no 
procs"  will  oe  sent  to  the  console  and  the  system  will 
c  rash  . 

3.   expand ( news i ze ) »  exDand ( newH , news ) 

a  .   Paramet  e  rs 

In  UNIX,  this  function  is  called  with  a  sinale 
argument,  the  new  reaion  size.  In  SUNIX  and  S  S  U  M I  X  ,  this 
function  is  called  with  a  pair  of  arguments:  the  new  data 
size  and  the  new  stack  size.  The  current  process's  PPOC  and 
UVECTOR  are     implied  parameters. 

b.   Functional  Description 

In  UNIx,  this  function  is  called  whenever  the 
size  of  the  current  process's  memory  image  chanaes.  It  puts 
the  new  size  in  p  <-  s  i  z  e  in  the  current  PPOC.  If  the  new  size 
is  smaller,  it  simoly  frees  the  unwanted  memory.  If  the  new 
size  is  laraer,  it  attempts  to  acauire  the  new  space  for  tne 
process.  If  it  succeeds,  it  cooies  the  process  image  to  the 
new  area.  If  it  fails,  it  causes  the  process  to  be  swapped 
out  with  the  new  sizes  noted  in  the  PPQC.  When  it  returns 
to  memory,  it  »»ill  return  at  the  new  size.  If  the  process 
is  swapped  out,  this  function  calls  "swtcn"  to  rescneoule 
the  process  immediately.   In  SUM IX  and  SSUNTx,  it   outs   the 
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two  new  sizes  in  o  *-  d  s  i  z  e  and  o  *-  s  s  i  z  e  in  the  PROC.  In  UNIX, 
t^e  function  calls  "xswao"  to  perform  the  swaDpinq 
operation.  In  SUNIX  and  SSUNIX,  the  new  function  "ceswap" 
is  used.  In  UNIX,  "sureg"  is  called  to  load  the  memory 
management  reoisters.  In  SUM  IX  ana  SS  U NIX  this  is  not 
necessary . 

c  .   Returned  Va 1 ues 

The  return  values  of  this  function  are  not 
checked.  The  caller  has  no  way  of  knowing  if  the  orocess 
was  increased  in  size  oy  direct  expansion  or  by  swapping. 
In  UNIX,  if  the  process  is  swapoed  out/  this  function  aoes 
not  return  to  its  caller.  The  return  comes  fro^  a 
subseauent  call  to  "swtch"  after  the  orocess  has  returnee  to 
memo ry  . 

a.   Error  Conditions 

This  function  has  no  error  conditions. 

4.   ceswao (ods , oss ) 

a .  Pa  rame t  e  rs 

The  parameters  are  the  current  orocess's  data 
and  stack  segment  sizes  in  64-Dvt?  Mocks. 

b.  Functional  Oescriotion 

This  function  is  oresenf  only  in  3 UNIX  and 
SSUNIX.  It  is  called  to  perform  core  expansion  swapping. 
It  calls  "xswap"  to  dc  the  actual  swaopinq  and  fhen  calls 
"swtch"  to  reschedule  t^e  process  immediately. 
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c.  Returned  Values 

This  function  does  not  return  to  the  caller. 
The  return  comes  from  a  suoseouent  call  to  "swtcn"  affer  the 
process  has  returned  to  memorv. 

d.  Error  Conditions 

This  function  has  no  error  conditions. 

F .   svsl  .c 

1 .   exec  (  ) 

a .  Par ame t e  r s 

The  currert  process's  UVECTOR,  PROC,  and  TEXT 
are  imolied  oarameters.  Because  this  function  is  a  s  v  s  t  e  m 
call/  the  array  u«-uarcU  in  the  UVECTOW  contains  additional 
arguments.   See  Ref.  11. 

b.  Functional  Descriot ion 

This  system  call  is  used  by  the  current  orocess 
to  invoke  a  new  program.  It  cooies  any  prooram  arguments  to 
a  buffer/  unlinks  from  the  old  TEXT,  frees  its  old  main 
memorv  soace>  establishes  a  new  TEXT  if  the  new  orogram  has 
shared  text>  acauires  memorv  soace  for*  the  new  data  and 
stack  segments^  clears  the  reaion  acquired,  reads  in  the  new 
program's  aata>  copies  the  arauments  to  the  new  stack,  and 
changes  the  memory  t anaoe^ent  registers  to  reflect  the  new 
address  soace.  In  UNIX*  "expand"  is  called  to  ^ree  the  old 
memorv  space;  in  S  U  N  i  X  and  SSUIMIX,  a  new  function,  "prfree", 
is  useo.   In  UNIX/  "estabur"  is  used   to   validate   the   new 
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memorv  reaui  rements?  in  SUNIX  and  SSUNIX,  t^e   new   function 

"cksize"    is    used.     In    SUNTX   and  SSUNIX,   only   the 

uninitialized  portion  of  the  data  segment  is  cleared   before 
the  copy  operation. 

c  .   Ret  urned  Va 1 ues 

This  system  call  returns  to  the  caller  only  if 
it  encounters  an  error.  If  no  error  occurs,  it  returns  to 
the  first  instruction  of  the  new  orogram. 

d.   Error  Conci  t ions 

This  function  returns  an  error  to  the  caller  if 
the  memory  reauirements  of  the  new  program  are     invalid. 

2.   ex  i  t ( ) 

a  .   Pa  rame t  er s 

The  current  process's  UVECTOR,  PROC,  and  TEXT 
are  implied  parameters. 

b.   Functional  Description 

This  function  is  the  system  call  used  to 
terminate  the  calling  process.  It  clears  all  signals, 
closes  anv  ooen  files,  unlinks  from  the  current  T  fc.  *  T  , 
acauires  a  block  or  the  swap  device,  cnpies  the  first  ?56 
bvtes  of  the  U VECTOR  to  the  Dlock,  ana  frees  main  memory 
soace  held  by  the  process.  in  SUNIX  and  SSUNIX,  the  old 
memory  area  is  freed  by  the  new  function  "prfree".  ,  T  h  e  ^  e  w 
function  "swfree"  is  used  to  free  any  swao  space.  In  S SUM  IX 
only,  if  a  orocess  has  the  SLOCK  bit  set  in   its   P^UC,   the 
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function  "shfree"  is  called  to  free  any  shared   core   assets 
that  the  crocess  has  been  allocated. 

c.  Returned  Values 

This  system  call  does  not  return  to  its  caller. 
The  next  function  invoked  for  this  process  is  "wai tH»  which 
completes  the  cleanup. 

d.  Error  Conci  t ions 

This  system  call  has  no  error  conditions. 

3  .   sbreak ( ) 

> 

a  .   Pa  rame t  ers 

The  current  process's  UVECTQ9  ana  PROC  are 
implied  parameters.  Pecause  this  function  is  a  system  call? 
an  aoitional  araument/  the  virtual  address  of  the  new  ena  of 
the  data/  is  found  in  the  array  u«-uaraU  in  the  UVECTOR. 

o.   Functional  Oescriotion 

This  function  is  the  system  call  used  to  change 
the  size  of  the  callina  process's  data  area»  Tt  calculates 
the  new  data  size  desired  bv  the  orocess  and  checks  fne 
validity  of  the  process's  new  total  memory  r eau i remen t s .  In 
UNIX,  "expand"  is  usee  to  establish  the  new  region.  Tn  UNIX 
and  SSUNIX,  this  function  atte^Dts  to  do  the  work  itself. 
It  puts  the  new  size  in  D«-asize  in  the  current  PRCC.  If  the 
new  size  is  smaller,  it  simolv  frees  the  excess  storaae.  If 
the  new  si  z°  is  1  a  r  a  e  r  ,  it  attemots  to  acauire  it.  If  this 
fails,   "ceswap"  is  called  to  acquire  the  soace  by  swapping. 
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In  all  systems/  the  newly  acquired  space  is  cleared. 

c  .   Ret  umed  Va  1  ues 

The  values  returned  bv  this  function  are  not 
chec  iced, 

d.   Error  Concisions 

If  the  new  storage  requirement  is  not  valid/  trie 
new  space  will  not  be  acquired  and  the  function  returns. 
This  will  usually  cause  the  process  to  terminate  abnormally 
because  of  a  memory  management  error. 

G .   text  .c 

1.   x swap Cp / f f / os ) /  x s wap (p / f f / ods / oss ) 

a  .   Pa  r^met  ers 

In  UNIX/  this  function  is  callea  wi  f  h  three 
arguments.  In  SUNIX  and  SSUNIX,  it  is  called  with  four. 
The  first  parameter  is  a  oointer  to  the  proc  of  a  process  to 
be  swapped  out  o*  memory.  The  second  parameter  is  the 
memorv  free  flaa.  Tn  U  N  T  X  /  the  third  parameter  is  the 
process  image  size  in  64-ovte  blocks.  In  SUNIX  and  SSUNIX, 
the  third  and  fourth  parameters  are  the  sizes  of  the 
process's  data  and  stack  seament-s  in  64-ovte  blocks. 

D.   Functional  Oescrict ion 

In  UNIX/  this  function  allocates  swap  space  for 
the  process  and  swaps  it  out.  In  SUNIX  ana  SSUNIX,  this 
function  allocates  soace  only  for  those   orocesses   t^at   do 
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not  already  have  it.  In  all  systems/  memory  is  freed  if  the 
memory  free  flag  is  set.  This  f 1 aq  will  not  be  set  if  t h i s 
function  was  called  Ov  "neworoc"  to  create  a  cooy  of  the 
parent  process.  In  SSUNTX,  when  this  function  is  called  to 
swap  out  a  Drocess  with  shared  core,  the  memory  free  flag  is 
not  set  if  other  memory-sharing  orocesses  remain  in  the 
sha  red  reo  i  on  . 

c .   Ret u  rned  Va 1 ues 

The  values  returned  dv  this  function  are  not 
chec  iced. 

a.   Error  Concitions 

If  swap  scace  must  be  allocated/  but  none  is 
available*  the  message  "out  of  swaD  soace"  will  be  sent  to 
the  console  and  the  svstem  will  crash.  If  an  output  error 
occurs  during  the  swao  operation/  the  messaae  "swap  error" 
will  be  sent  to  the  console  and  t  *  e  system  will  crash. 

Z .   xa 1  1 oc ( i  pi 

a .   Parameters 

The  parameter  is  a  Dointer  to  the  i node  of  tne 
text  segment  that  is  to  be  allocated  or  located.  The 
current  process's  UVECTOR  and  P  R  0  C  and  all  TEXTS  are  implied 
pa  r ame t  e  r s  . 

D.   Functional  Descriotion 

This  function  establishes  the  shared  text 
segment   r  e  a  u  i  r  p  d   by   the   current  process.   I ^     the  current 
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process  does  not  reauire  shared  text/  this  function  simply 
returns.  If  the  process  does  reauire  snared  text/  this 
function  searches  the  array  of  TEXTS  for  a  previously 
established  TEXT  for  the  reauested  segment.  Tf  one  is 
found/  its  active-process  use  count  is  incremented.  Tf  the 
requested  segment  is  in  memory/  the  TEXTs  in-memory  count  is 
incremented.  If  a  TEXT  has  not  Deen  established/  an 
unallocated  TEXT  is  located  and  allocated  to  the  text 
segment.  Swan  space  is  allocated  for  the  text  seoment  .  The 
current  process's  adcress  space  is  increased  using  "exoand" 
to  acauire  space  for  the  new  text  segment.  The  text  seoment 
is  then  read  into  memory  and  cooiea  to  the  swac  space 
allocated  for  it.  The  new  memory  space  acquired  for  the 
text  seamen!  is  freed  using  "  e  x  o  a  n  a  "  in  U  w  I  X  and  "prfree"  in 
SUNIX  and  SSUMIX.  The  address  of  the  TEXT  is  placed  in 
p«-textp  in  the  current  PROC  and  the  process  is  swapped  out 
of  memory.  When  it  returns  to  memory/  the  newly  established 
text  segment  will  return  with  it. 

c.  Returned  Values 

The  value  returned  by  this  function  is  not 
chec  keo . 

d.  Error  Conci  t ions 

If  a  TEXT  must  be  established  and  one  is  not 
available/  the  message  "out  of  text"  will  oe  sent  to  »■  n  e 
console  ana  the  svsten-  will  crash.  If  swap  space  must  be 
allocated  and  none  is  available,  the  messaae  "out  of  swan 
soace"  will  oe  sent  to   the   console   ana   the   system   will 
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crash. 

H .   cage . c 

1.  pralloctpr) 

a .   Pa  ramet  ers 

The  parameter  is  a  oointer  to  a  PROC.  The  TEXT 
pointed  to  by  the  PROC  is  an  implied  parameter. 

o.   Functional  Description 

This  function  is  present  only  in  S  U  N I X  and 
S  S  U  N  I  X  .  It  acquires  re^ory  soace  for  the  process's  UVECTOR, 
data  seament/  stack  segment/  and/  if  necessarv/  shared  text 
segment.  Soace  for  the  t  e  x  *•  segment  is  acauired  only  if  the 
text  is  not  resident  in  main  memory.  If  allocation  fails* 
all  memory  space  previously  allocated  is  freed. 

c  .   Returned  Va 1 ues 

If  all  allocations  ar^  successful/  the  physical 
block  number  of  the  base  of  the  UVECTOR  is  returned.  If  anv 
allocation  fails/  a  zero  is  returned. 

d.   Error  Concitions 

A  return  value  of  zero  indicates  an  error  to  the 
ca 1 1 er . 

2.  .   p  r  swap  (  rp  ) 
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a  .   Parame t  ers 

The  first  parameter  is  a  o  o  inter  to  a  p  R  0  C  .  The 
TEXT  pointed  to  by  the  PROC  is  an  implied  parameter. 

o.   Functional  Description 

This  function   is   Dresent   only  in   SUNIX   and 

S  S  U  N I  X  .    It   swaos  a  process's  UVECTOR,  data  segment/  stack 

segment/  and/  if  necessary/  text-  seament  into  main  memory. 

c.  Returned  Values 

The  value  returned  by  this  function  is  not 
chec  ked. 

d.  Error  Concitions 

If  an  input  error  occurs  durinc  the  swao 
ooeration/  the  message  "swao  error"  is  sent  to  the  console 
and  the  system  will  crash. 
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II.   APPENDIX  C:  SYSTEM  BENCHMARKS 


A.   BENCH  1,  MONOPROGRAMMING 


chdir  /usr/sys 

sh  rp 1 oad 

chdir  ken 

cc  -0  -c  slo.c 

cd 

cd  dm  r 

ed  ipc.c  </us r /bene h /edemd  >/dev/nul 1 

chair  /us  r /bench 

cc  -0  rf test  .c 

bas  tower<towerin>/dev/nul 1 

od   /usr/sys/conf /mlS.s  >/dev/nul 1 

co  /usr/unix  /dev/nu) 1 

chdir  /bin 

sum  *>/dev/nu 1 1 

wa  i  t 

chdir  /usr/sys/ken 

rm  s 1 o  .  o 

chdir  /usr/bench 

rm  a .out 


B.   BENCH  2,  MULTIPROGRAMMING 

chdir  /usr/sy  s 

sh  rp 1 oad& 

chdir  k e  n 

cc  -0  -c  s 1 o . c& 

cd 

cd  dmr 

ed  ipc.c  </usr/bench/edcmd  >/dev/nul  I  ■'< 

chdir  /usr/bench 

cc  -0  rf test .c& 

Das  t Owe r< tower i n>/dev/nu 1 1 & 

od   /us r/sy s/con f /m^5  .  s  >/dev/nu!1& 

cd  /usr/unix  /aev/nul  1  i 

chdir  /bin 

sum  *>/dev/nulU 

wa  i  t 

chdir  /usr/sys/ken 

rm  s 1 o  .  o 

chdir  /us  r /bene  h 

rm  a . ou t 
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